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Government -wide  testing  of  COBOL  Compilers  is  the 
rerpo.i.lbi  1 ity  of  the  Federal  COBOL  Compiler  Testing 
^^^Servic*,  an  activity  of  the  Department  of  the  Navy's 
^^^Auto:'i,.t  ic  Data  Processing  Kquipment  Selection  Office, 
•'Software  Development  Division.  In  May  1974,  the  Amcr- 

Oican  National  Standards  Institute  approved  ANS  Pro- 
gramming Larguage  COBOL,  X 3. 23-1574  as  the  national 
standard  for  the  COBOL  language.  Spec  I f icat ions  for 
^^^this  »evision  were  drawn  from  USA  Standard  COBOL  X3.23- 
^^■■*1968  and  tl.e  CODASYL  COBOL  Journal  of  Development, 

O dated  31  December  1971.  As  a remit,  the  Testing  Ser- 
vice is  engaged  in  the  development  of  a COBOL  Compiler 
^5IV|l*dat  ion  System  for  this  new  standard,  incorporating 
tests  for  the  revised  language  into  the  existing  196ft 
COBOL  Compiler  Validation  System.  'Ihe  first  part  of 
the  paper  focuses  on  the  rationale  behind  changes  from 
the  '63  to  '74  COBOL  Standard  as  well  as  highlighting 
t bo  new  features  in  the  language.  The  second  part  of 
the  paper  discus  evolution  vlthin  the  COBOL  lan- 
guage itself  with  respect  to  the  CODASYL  COBOL  Journal 
of  Development  and  several  other  CODASYL  language 
activities. 

/ 

IN i REDUCTION 

The  first  part  of  this  paper  will  focus  on  the 
rationale  behind  changes  from  the  '63  to  the  '74  COBOL 
Standard  or.  well  as  highlight  the  new  features  in  the 
language.  All  comments  made  with  regard  to  COBOL  '68 
or  COBOL  '74  will  be  bused  or  the  language  as  defined 
i.i  References  3 and  2,  respectively. 

The  second  part  of  the  paper  will  discuss  evolu- 
tion within  the  COBOL  language  itself  with  respect  to 
the  CODASYL  COBOL  Journal  of  Development  and  several 
other  CODASYL  language  activities. 

BACKGROUND 


Sin^e  1 July  1972,  all  COBOL  compilers  brought 
into  the  Fed«?ral  Government  have  to  be  identified  as 
Implementing  one  of  the  levels  of  the  Federal  COBOL 
Standard.  The  National  Bureau  of  Standards,  which  has 
the  responsibility  for  the  development  and  maintenance 
of  Federal  aDP  Standards,  has  delegated  to  the  Depart- 
ment of  Defense  the  responsibility  for  the  opetatlon 
of  a Government -wide  COBOL  Compiler  Testing  Service. 
This  responsibility  is  discharged  hy  the  Federal  COBOL 
Compiler  Testing  Service  (FCCTS),  an  activity  of  the 
Dcj.irtT.tnt  oi  the  Navy's  Automatic.  Data  Processing 
|F.quipment  Select  ion  Office  Software  Development  Divi- 
sion, through  the  implementation  and  maintenance  of 
|th<*  COBOL  Compiler  Validation  System  (CCVS)^,  a com- 
|prchensivc  set  of  computer  programs  used  to  test  COBOL 
'compilers  for  compliance  with  the  Federal  COBOL  Stan- 
dard. 

In  May  1974,  the  American  National  Standards  In- 
stitute appro /<d  ANS  Programming  language  COBOL,  X3.23- 
1974  (COBOL  '74)  ns  the  national  standard  for  the 


COBOL  language  replacing  USA  Standard  COB  L,  X3.23- 
1968^  (COBOL  ’68).  Lunguege  specifications  i v this 
revision  were  drawn  from  the  COJOi  '66  and  the  CODASYL 
COBOL  Journal  of  Development^  (JOd)  dated  il  December 

1971. 

Federal  Information  Processing  Stand.udr  Publica- 
tion 21-1*  adopts  X 1.23-1^74  (minus  the  R.port  Wri’ci 
module)  a*,  the  Federal  COBOL  Standard,  as  result  of 
these  actions,  the  Testing  Service  is  enraged  in  the 
development  of  a '74  COBOL  Compiler  Validation  System, 
incorporating  tests  for  the  revised  language  into  the 
existing  operational  ’68  uOROL  Compiler  Validation 
System . 

Appendix  A of  the  XJ. 23-19 74  Standard  presents  a 
history  of  COBOL.  As  on*»  follows  the  history  of 
changes  to  the  Standard,  one  looks  for  a planned  di- 
rection and  growth  of  the  COBOL  language.  Do  we  set 
evolution  toward  a "foreseeable"  futair  .a^g-nge  spec- 
ification and  standard?  11  no,  can  v*»  state  the  final 
specifications  to  see  where  wc  st^nd  along  the  road  of 
progress?  If  it  appears  that  we  cannot , then  where  is 
COBOL  headed  with  respect  to  the  revision  of  COBOL  '74 
and  the  CODASYL  Journal  of  Develop  cut  ? 


CRITKRIA  FOR  IN  ILF  STANDARD 

; < ' ’ - I ' ■ 

When  considering  all  changes  made  in  the  rev i slur, 
process  from  COBOL  '68  to  COBOL  '74,  otic  rust  consider 
the  eight  criteria  against  which  each  pi  op o sod  change 
was  measured.  These  were  chosen  and  published  by  the 
X3J4  committee  in  Section  2.1  of  Appendix  B of  the 
X3. 23-1974  Standard,  and  are  shown  here  for  later 
ref  erence : 

(1)  The  general  usefulness  of  an  element  or 
function  in  terms  of: 

a.  The  degree  of  implement  at  ion; 
h.  Acceptance  by  users; 
c.  The  degree  to  which  a function  was 
required . 

(2)  The  overall  functional  capability  of 
the  language,  considering  such  things  as  redundancy. 

(3)  The  state-of-the-art  technology  with 
regard  to  implementing  the  language  feature. 

(4)  The  usefulness,  in  toms  of  application 
requirements,  of  language  capabilities  within  each 
level  of  a module. 

(5)  Compatibility  w«th  other  standards. 

(6)  The  cost  of  implement lng  versus  advan- 
tages of  use. 

(7)  Overall  language  consistency  within  a 
defined  level  or  module. 


Ill 


le. 


(8)  Upward  compatibility  of  levels  within  ft 


After  executing  the  above  INSPECT  statement  l.D-1  vou  l ' 
cont « in: 


\ 
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One  must  carefully  • ..amine  each  of  these  eight 
Terla  and  ask  whether  the  impact  of  the  proposed 
'•e  to  the  language  is  measurable  as  a quantity 
liars  and  cents),  or  is  measurable  only  in  a quail- 
vo  sense  (relatively  good  or  bad).  When  a vendor 
cs  a qualitative  Judgment  with  respect  to  a stan- 
how  objective  can  his  representative  be?  We  all 

• realize  that  vendors  have  a large  investment  in 
. <I*.Mng  software  products  which  ray  include  certain 

guage  elements  and  features  ti.  t are  extensions  to 
* • current  standard. 

As  the  changes  in  the  Standard  for  COBOL  are  pre- 

ted,  it  will  be left  to  the  reader  to  dec  id  . v/heth- 

ssdi  chat  truly  accessary  and  follows  tha  pub'- 

bed  policy  for  change  (the  aforem  ntioned  eight 
iteria).  ThJs  is  because  most  DP  managers  will  face 
•f.c  decision  as  to  whether  to  implement  COBOL  '74  at 
their  installations. 

REVISIONS  TO  THE  COBOL  *68  MODULES 
AND  NEW  FEATURES  OF  COBOL  *74 

Nucleus,  Sequential  1-0  and  Library  modules  of 
M»OL  '68  have  undergone  major  revisions.  The*  Seg- 

* at  ion  module  is  essentially  the  same  as  in  the 

•*  COBOL  Standard.  The  Random  Access  module  has  been 

• placed  by  two  new  modules.  Relative  1-0  and  Indexed 
O,  and  the  specifications  for  the  Report  Writer  mod- 

v le  have  been  rewritten.  Addition  of  the  MERGE  verb 
has  expanded  the  SORT  module  into  the  Sort-Merge  rood- 
It,  and  the  Table  Ha. idling  module  consists  of  two 
levels  instead  of  the  previous  three,  but  is  otherwise 
tie  changed.  Section  2.3  of  Appendix  B of  the 
.23-1974  Standard  documents  in  greater  detail  the 
raodif Ications  made  to  the  1968  Standard  and  the  addi- 
nal  language  features  added  for  the  1974  Standard. 

In  the  remainder  of  this  section  we  concentrate  on 
the  new  features  of  the  Nucleus  and  Library  modules. 

1 he  1 -0  modules  will  be  covered  in  a later  section,  and 
vc  ignore  the  Report  Writer  since  it  is  beyond  the 
scope  of  the  FeJeral  Standard. 

Three  new  verbs  have  been  added  to  the  Procedure 
Division  of  the  Nucleus  module;  INSPECT,  STRING,  and 
^STRING.  The  INSPECT  verb  replaces  the  old  EXAMINE 

• b and  provides  expanded  editing  capabilities  of 
Itiier  single  characters  or  groups  of  characters  in  a 

uata  item.  For  each  of  these  INSPECT  functions,  the 
f KE  or  AFTER  phrase  allows  one  to  specify  that  the 
function  begins  or  ends  upon  encountering  a given  char- 
acter or  string  of  characters. 

As  an  example  of  the  INSPECT  statement,  consider 
the  following  source  code: 

DATA  DIVISION  entries 

01  ID-1  PIC  XOA)  VALUE 

'$$0KnATtiWMDZDVC7MMMW$M 

’defenseWMWMiWdetaxl1  . 

VI  ‘ N.EPURE  DIVISION  entries 

INSPECT  ID-1  REPLACING  ALL  ' tftfDI'  BY  ’THE*' , 
FIRST  'A'  BY  'E\ 

FIRST  'MW  BY  'HOF#*, 

FIRST  'T*  BY  *K'  AFTFR  INITIAL  'UC\ 

FIRST  'iWMMM'  BY  ’#GOg0VF.RU\ 

FIRST  'S'  BY  'C' 

FIRST  'iMMttt'  BY  •liBKFORP.IT 
AFTER  INITIAL  'EN\ 


'THE|lFEEThOKHTHEKDUCKl{GO|lOVERliTHE»lr,.:-;i:EyiJLFOKF.KTHl^ 

TAIL*  . 

This  example  points  out  one  of  the  limitation'  on 
the  use  of  INSPECT;  the  number  of  characters  being  re- 
placed must  equal  the  number  of  characters  by  which 
they  are  replaced.  Thus,  *DE‘  cannot  he  replaced  by 
'THE|T  hut  the  characters  ' fcitfDE * can  be*  replaced  by 
’THE#* . 

By  removing  F.XAMINF  from  the  COBOL  reserved  word 
list  in  the  COBOL  '74  compilers,  both  vendors  and 
users  must  transform  all  uses  of  the  EXAMINE,  to  the 
new  expanded  syntax  of  INSPECT.  TALLY  is  no  longer  a 
special  register  provided  by  the  compiler  and  would 
need  to  Le  added  to  the  DATA  DIVISION  of  every  appli- 
cation program  which  references  it.  Although  trans- 
lators could  change  simple  occurrences  of  EXAMINE  to 
INSPECT,  more  complex  EXAMINE  statements  would  have  to 
be  manually  translated.  ‘The  cost  for  this  process 
will  be  considerable;  however,  no  data  for  the  totai 
number  of  occurrences  of  EXAMINE  in  all  applications 
for  all  COBOL  users  is  available. 

. With  the  1974  Standard,  the  COBOL  language  has 
the  features  necessary  for  manipulation  of  character 
strings  without  each  individual  character  string 
beginning  in  the  leftmost  character  position  of  a data 
item.  The  STRING  statement  allows  a user  to  build  a 
single  data  item  from  two  or  more  data  items.  The 
sending  data  items  may  be  delimited  by  one  or  more 
character(s) , or  the  entire  sending  item  can  be  part 
of  the  receiving  item.  A user  can  also  indicate  the 
relative  starting  position  in  the  receiving  item  for 
the  STRING  option. 

The  following  example  Illustrates  the  use  of  the 
STRING  statement . 

DATA  DIVISION  entries 

01  WISH-LIST. 

02  FILLER  PIC  X(4)  VALUE  'GEF.lT. 

02  FILLER  PIC  >(33)  VALUE  SPACES. 

01  R EL-POSITION  PIC  99  VALUI  S. 

01  STRING-VALUES. 

02  FIELD1  PIC  X(14) 

VALUE  * T|(WISH|fI  ,/UYUU* . 

02  FI ELD 2 PIC  X(24) 

VALUE  ' WAS#A|iFORTKAN|iPR<  K. RAMMER ' . 

PROCEDURE  DIVISION  entries 

PARAGRAPH-1. 

STRING  FIELD1  DELIMITED  BY 
SPACES,  FIEI.D2  DELIMITED  BY  SIZE 
INTO  WISH-LIST  WITH  POINTER  REL-P0S1T10N, 
ON  OVERFLOW  CO  TO  PARAGRAPH-2. 


PARAGRAPH -2. 

After  the  execution  of  the  STRING  statement,  the  data 
item  WISH-LIST  contains  'GF.EtfltfWISIItf lKWAS#AlfFORTRANtf- 
PROGRAMMER ' . 

The  opposite  is  achieved  by  the  UNSTRING  statement 
which  causes  data  in  a sending  field  to  be  separated 
based  on  one  or  more  delimiters,  and  placed  into  mul- 
tiple receiving  fields.  A delimiter  may  be  a single 
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character  or  a combination  of  characters. 


The  SIGN  clause  allows  a user  to  specify  whether 
a separate  character  position  is  used  for  the  sign  in 
numeric  items  and  to  indicate  whether  the  position  of 
the  sign  is  leading  or  trailing. 

The  PROGRAM  COLLATING  SEQUENCE  clause  permits  one 
to  specify  ASCII,  or  some  other  collating  sequence. 
However,  changing  the  collating  sequence  for  a program 
will  necessarily  require  consideration  of  all  state- 
ments which  depend  upon  a character's  relative  posi- 
tion in  a given  collating  sequence;  for  example,  the 
SEARCH  statement,  the  SORT/MERGE  statement,  and  alpha- 
numeric comparisons  in  an  Iir  statement. 

Several  major  changes  have  been  made  to  the. Li- 
brary module.  There  are  no  restrictions  now  on  where 
a COPY  stateaicnt  may  appear  in  a COBOL  program.  A 
COPY  sentence  may  appear  anywhere  that  a COBOL  word 
may  appear.  As  a result,  rather  strange  looking  source 
code  can  result r e.g., 

ADD  COPY  XX.  TO  B. 

If  the  content  of  the  library  text  XX  contains  the 
single  identifier  A,  the  results  after  the  COPY  takes 
place  are: 

ADI)  A TO  B. 

There  can  be  more  than  one  library  available  at 
compile  time.  In  this  case  the  COPY  sentence  must 
contain  the  name  of  the  library  in  which  the  text  re- 
sides. The  presence  of  the  REPLACING  phrase  in  a COPY 
sentence  causes  the  library  text  being  copied  to  be 
edited  prior  to  being  inserted  in  the  program.  There 
are  several  levels  of  editing  that  can  be  used.  Words, 
literals,  identifiers  and  pseudo-text  can  be  replaced 
by  like  or  different  types  of  operators. 

Pseudo-text  is  bounded  by  pseudo-text  delimiters, 
which  are  matching  sets  of  double  equal  signs  (*■) . 

The  replacement  of  pseudo-text  is  based  on  finding  a 
matching  set  of  charact er-str ing(s)  contained  in  the 
library  text.  The  replacement  string  may  be  longer  or 
shorter  than  the  characters  replaced. 

The  following  COPY  statement  Illustrates  the  use 
of  pseudo-text  to  edit  a library  entry. 

User's  COBOL  Library  LIBRARY-TEXT 

01  ID1  PIC  X(54)  VALUE  IS 

'iJdfffahIdeductUdefenseiJdetail 

'unwMWMtwutnMiM' . 

COBOL  Source  Statement : 

COPY  LIBRARY-TEXT  REPLACING 
~#DE—  BY  — ' THE#— 

—AT—  BY  — ETtfOFtf— 

— CT—  BY  — CKtfGOHOVER#— 

— SE—  BY  — CEtfBEFOREtf— 

The  compiled  results  of  a program  with  the  above 
COPY  statement  are  the  same  as  a program  In  which  the 
following  source  code  appeared: 

01  ID1  PIC  X(54)  VALUE  IS 

* THE#  FEETKOFUTH  Etf  DUCKtfCOtloV F.RIf 
- 'TH  Elf  FENCEbBEFORUfTH  ENTAIL' . 

Here  we  have  a definite  expansion  of  capabilities 
of  an  exlating  language  element.  This  should  aid  In 
•atabllahing  and  constructively  using  production  pro- 
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THE  INPUT-OUTPUT  MODULE? 

The  major  enhancement  of  COBOL  '74  over  COBOL  *68 
is  in  the  revision  to  the  input -o  it  >ut  modules.  The 
Sequential  i-0  module  has  been  revised,  and  the  Rnndo.i 
Access  module  has  been  replaced  by  two  new  modules; 
Relative  1-0  and  Indexed  I-O,  with  some  degree,  of 
functional  and  syntactic  similarity  e<istJ ig  l -c? ween 
the  new  Relative  1-0  module  and  the  old  Random  Access 
module.  Taken  as  a group,  the  three  1-0  modules  pro- 
vide the  COBOL  programmer  with  file  handling  capabil- 
ities which  are  well  beyond  what  has  been  possible 
previously. 

The  features  of  the  three  1-0  modules  as  well  as 
file  maintenance  capabilities  are  described  in  detail 
in  "An  Overview  of  the  197 A COBOL  Standard"**. 

OTHER  NEW  MODULES 

In  the  1968  Standard  there  were  no  explicit  pro- 
cedures for  specifying  what  debugging  actions,  if  any, 
would  take  place  during  the  execution  of  a COBOL  pro- 
gram. The  DEBUG  module  for  the  1974  Standard  includes 
language  elements  which  are  designed  for  debugging 
COBOL  programs.  Their  inclusion  in  the  COBOL  lan- 
guage permits  a user  to  consider  the  debu/glng  of 
source  programs  in  the  design  of  an  application,  not 
as  an  afterthought  when  problems  are  encountered. 

The  USE  FOR  DEBUGGING  statement  identifies  the 
user  items  that  can  be  monitored  by  the  associated 
debugging  section . The  debugging  algorithm  which  is 
defined  in  the  debugging  section  can  be  controlled  by 
both  a compile  tine  switch  and  an  execution  time 
switch.  Debug  lines  are  source  statements  whose  in- 
clusion or  omission  from  an  object  program  is  con- 
trolled by  a compile  time  switch.  There  is  a special 
register  called  DEBUG-ITEM  which  can  be  accessed  in 
debugging  sections.  This  special  register  contains 
information  relative  to  the  source  code  which  causes 
the  execution  of  a debugging  section. 

The  increased  size  of  source  and  object  programs 
will  add  to  the  cost  to  compile  and  execute  applica- 
tion programs  using  DEBUG;  this  must  be  carefully 
measured  and  compared  to  the  expected  savings  in  the 
program  development  process. 

The  Inter-Program  Communication  module  provides  a 
means  for  a program  to  transfer  control  (CALL  and  EXIT 
PROGRAM)  to  one  or  more  subprogram.*,  and  the  sharing  of 
data  among  these  programs  (LINKAGE  SECTION  and  USTNG) . 
The  action  to  be  taken  when  there  is  not  enough  object 
time  memory  can  be  specified  (ON  OVERFLOW)  and  the 
memory  areas  occupied  by  called  programs  can  be  re- 
leased and  made  available  to  the  operating  system 
(CANCEL) . 

There  are  implementor-defined  areas  in  the  Inter- 
Program  Communication  module  which  could  cause  pro- 
blems in  program  portability  between  systems.  For 
Instance,  the  relationship  between  the  operand  in  the 
CALL/CANCEL  statement  and  the  referenced  program  is 
implementor-defined.  This  means  that  even  though  the 
program-name  is  a user-defined  word  and  thus  could 
be  30  characters,  the  Implementor  may  limit  the  actual 
number  of  characters  which  are  used  to  establish  link- 
age between  the  called  and  calling  programs.  If  a 
user  has  subprograms  on  a system  which  recognizes  the 
first  10  characters  of  the  program-nane  and  moves  to 
an  implementation  which  recognizes  only  the  first  six, 
than  any  referenced  progrnm-names  with  the  first  six 


characters  identical  would  be  treated  ok  referencing 
the  same  subprograms. 

The  motivating  factor  behind  including  the  COMMU- 
NICATION module  in  COBOL  '74,  was  the  advent  within 
tin  past  decade  of  computer  systems  using  remote  ter- 
•n* rials  and  the  use  of  these  terminals  for  message  pro- 
cessing .applications.  The  Communication  module  pro- 
vides four  new  I/O  verbs  (RECEIVE,  SEND,  ENABLE,  D1S- 
AB1F)  and  the  capability  of  interfacing  COBOL  programs 
to  any  configuration  of  remote  terminals  via  a set  of 
message  queue* . The  operation  of  the  message  queues 
and  the  remote  terminals  is  handled  by  an  implementor- 
defined  Message  Control  System  (VIS). 

The  basic  problem  with  the  Communication  module, 
as  ir  now  stands,  is  that  the  MCS  and  its  Interface  to 
the  network  of  peripheral  devices  is  so  ill-defined. 
Although  the  concept  of  the  MCS  is  never  formally  in- 
troduced except  in  Appendix  C of  the  Standard,  its 
existence  is  implied  throughout  the  specification  for 
the  Communicat ion  module  by  frequent  references  to  it 
l the  MCS)  by  name.  Unfortunately,  the  appendices  are 
not  considered  a part  of  the  formal  COBOL  language 
specification;  and  thus  they  are  in  no  way  binding.  At 
best,  the  appendix  can  be  considered  a suggested  guide- 
line for  implementation.  In  other  words,  it  can  only 
serve  to  enlighten  the  reader  as  to  what  the  Program- 
ming Language  Coonlttee  (PLC)  of  the  Conference  on 
Data  Systems  Languages  (CODASYL)  might  have  had  in  mind 
when  it  designed  the  specification  for  the  Communica- 
tion module. 

EVOLUTION  OF  COBOL 

Having  presented  an  overview  of  changes  and  new 
features  from  COBOL  '68  to  COBOL  '74,  one  can  explore 
the  question  of  growth  in  the  COBOL  language  with  res- 
pect to  Operating  System  Command  Languages  (OSCL) , 
data  base  efforts  in  Data  Definition  Language  (DDL) 
and  Data  Manipulation  Language  (DML) , and  mini-COBOL 
efforts . 

There  is  current  international  Interest  and  ac- 
tivity in  the  area  of  a standardised,  user  oriented 
operating  System  Command  Language  (reference  CODASYL 
OSCL  Task  Croup  and  IFIPS  TC-2  Working  Conference  on 
Command  Languages).  The  file  manipulating  features, 
Inter-Program  Communication  and  Communication  modules 
of  COBOL  '74  relate  to  this  subject  area.  There  has 
far  been  no  formal  coordination  between  CODASYL'S 
PLC,  ANSC  X3J4,  and  the  OSCL  groups  on  possible  stan- 
dard features  of  operating  systems,  status  and  con- 
ditions, and  error  responses  to  the  user.  It  is  es- 
sential that  future  coordination  between  these  and 
blnilnr  groups  be  accomplished. 

Currently  we  see  a host  of  new  implementations  of 
dal  a base  management  systems.  How  these  systems  will 
relate  to  the  work  of  the  Data  Rase  Language  Task 
Group  of  CODASYL'S  Programming  Language  Committee  is 
yet  to  be  determined.  The  stated  purpose  of  PLC's 
DBLTG  is  to  prepare  a proposal7  to  Include  in  COBOL 
a data  base  facility  which  is  based  on  the  April  1971 
DBTC  Report.  ANSC  X3J4,  user,  and  vendor  acceptance 
of  this  effort  will  be  determined  in  the  near  future. 


"The  object!..'  are  to  make  possible:  cor - 
patible,  uniform,  source  programs  and  object 
results,  with  continued  reduction  in  the 
number  of  changes  necessary  for  conversK. 
or  interchange  of  source  programs  and  data. 
The  PLC  concent  rates  its  efforts  in  the  area 
of  tools,  techniques,  and  ideas  aimed  at  the 
programmer." 

Evolution  of  COBOL  is  a dynamic  process  as  noted 
in  Section  2.2.1  of  Appendix  B of  the  X3. 23-1974  Stan- 
dard : 

"Since  the  language,  and  hence  the  JOD,  is 
constantly  changing,  it  was  necessary  to 
select  the  JOD  of  a given  date  to  serve  as 
a base  document  for  the  revision  process. 
This  date,  known  as  the  cutoff  date,  was 
December  31,  1971.  Changes  to  the  language 
after  that  date  were  considered  for  inclu- 
sion only  where  they  were  in  response  to 
X3J4  proposals  or  where  they  affected  items 
whose  final  disposition  had  been  deferred 
by  X3J4  pending  specific  PLC  action." 

Evolution  in  COBOL  is  shown  in  Section  2.2  of  the 
JOD.  Each  modification  began  as  a written  proposal 
whose  format  and  content  are  shown  in  the  Acknowledg- 
ment on  Page  ill  of  the  JOD.  Every  written  proposal 
to  PLC  is  discussed  and  voted  upon.  The  acceptance 
of  a proposal  is  determined  by  a rather  sophisticated 
voting  procedure  based  upon  a percentage  of  members 
present  at  the  meeting.  In  contrast  to  the  ANSC  X3J4 
committee's  eight  criteria  for  accepting  a proposed 
change  (whether  it  be  a minor  or  a radical  change  to 
the  language),  no  Buch  published  criteria  exist  for 
CODASYL'S  PLC.  This  points  out  the  contrasting 
philosophy  in  the  COBOL  language  development  commit- 
tee vs.  the  COBOL  language  standards  committee. 

Whereas  the  development  group  feels  a need  to  be  un- 
constrained In  keeping  COBOL  a growing  "living"  lan- 
guage, the  standards  group  has  an  obligation  to  main- 
tain a standard  COBOL  specification  against  which  a 
particular  implementation  can  be  measured  (validated) 
for  conformance.  With  this,  a user,  such  as  the  Fed- 
eral Government,  con  Insure  transportability  across 
different  computer  systems.  The  effective  lifespan 
of  a COBOL  application  program  is  a very  important 
aspect  in  judging  the  cost  effectiveness  of  that 
application  program  written  in  the  COBOL  language  as 
opposed  to  other  possible  computer  languages. 

In  answer  to  the  question  of  "foreseeable"  future 
language  specification  for  COBOL,  as  long  as  the  COBOL 
language  will  continue  to  evolve  to  try  to  meet  the 
changing  needs  of  the  business  data  process ing  com- 
munity (as  determined  by  CODASYL's  PLC),  no  "flaal" 
specification  is  possible.  As  for  the  revision  to 
COBOL  '74,  since  the  Standard  COBOL  is  based  largely 
upon  a reference  JOD,  rather  significant  changes  can 
be  expected  again  as  with  the  revision  of  COBOL  '68. 
These  changes  require  a certain  amount  of  conversion 
for  both  the  venJor's  compilers  and  the  user's  appli- 
cation programs. 

; CONVERSION  IMPACTS 


Since  the  CODASYL  Programming  Language  Committee 
(PIX)  Is  responsible  for  the  continuing  development  of 
the  COBOL  language  it  is  important  to  understand  how 
this  group  functions  with  respect  to  accepting  pro- 
posals for  changes  to  COBOL  and  publishing  the  JOD  when 
these  changes  have  been  agreed  upon. 

In  Section  2.1.4  of  the  JOD,  one  finds  tha  stated 
purpose  and  objectives  of  PLC  as  follows: 


COBOL  '74  will  be  expensive  to  implement  for  both 
the  vendors  and  users.  Exactly  how  expensive  is  yet 
to  be  determined.  Actual  cost  should  be  calculated, 
at  least  after  the  fact,  and  given  to  ANSC  X3J4  as 
reference  data  for  the  next  COBOL  Standard.  Trans- 
lators need  to  be  developed  and  provided  to  the  whole 
COBOL  ccmaunity  as  a tool  to  aid  the  overall  conver- 
sion. The  users  must  see  that  this  product  is  shared 
by  all,  especially  in  the  Federal  Community,  since  all 


ll* 


taxpayer*  will  pay  for  the  higher  conversion  cost  If 
they  are  not  willing  to  cooperate  with  each  other. 
One  solution  to  generalized  conversion  can  be  seen  li 
the  paper  describing  the  "System  for  Efficient  Pro- 
tram Portability"9. 


RECOMMENDATIONS 


There  remains  a need  to  define  the  COBOL  language 
formally.  Both  the  syntax  and  semantics  should  be 
expressed  as  formal  grammars  and  defined  In  an  appro- 
priate metalanguage.  This  would  aid  In  pinpointing 
the  ambiguities  in  the  language  and  leave  no  doubt  as 
to  what  Is  valid  and  what  is  not.  This  would  be  a 
great  help  In  measuring  conformance  to  the  COBOL  lan- 
guage (as  described  in  the  JOD)  and  to  the  COBOL  Stan- 
dard (COBOL  ’74). 


COBOL  '74  Is  In  many  ways  a vast  improvement  over 
COBOL  '68.  New  features  have  been  added  which  contrlb- 
ute  to  the  capability  of  the  language  (the  new  1-0 
modules),  enlarge  Its  scope  (the  Communication  Module) 
and  enable  the  programmer  to  produce  a better  product 
(the  Intcr-Progam  Communication  and  Debug  modules). 
Furthermore,  old  modules  have  been  enlarged  and  Im- 
proved. CODASYL  PLC  and  ANSC  X3J4  deserve  tremendous 
praise  for  their  efforts.  This  paper  suggests  that 
users  and  vendors  unite  in  helping  to  honestly  evalu- 
ate and  improve  COBOL  '74.  When  problems  arise  In 
attempting  to  implement  COBOL  '74,  those  problems 
should  be  brought  to  the  attention  of  the  entire  COBOL 
community. 
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